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PREFACE 

This  paper  describes  a  communications  component  for  an 
online,  graphical,  simulation  system  operating  in  a  multiterminal 
environment.   The  desired  features,  hardware /software  tradeoffs, 
and  other  design  considerations  of  the  overall  system  are  "briefly 
discussed  followed  by  a  description  of  the  communications  package. 
The  current  implementation  level,  problems,  and  possible  develop- 
mental trends  are  also  described. 
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I.      THE  CURRENT  ENVIRONMENT 

The  utility  and  advantages   of  interactive  online  graphics 

terminals  have  been  well  demonstrated  over  the  past  several  years. 

2 
The  effectiveness   of  simiilation  studies  is   obvious .        A  marriage   of 

3 
the  two  is   also  clear  and  has   already  been  performed  many  times. 

However,  powerf\il  graphical  simxolation  systems   are  not  at  all  common, 

and  are  in  fact  only  in  regular  use   at   a  small  number  of  large 

commercial   conipanies   and  government  agencies.      Two  primary  reasons 

for  this   resiolt  are  high   cost  and  low  flexibility. 

Typically,   a  large   CPU  with  extensive  peripherals   is   used 
to  service   at  most  two  or  three   directly  attached  graphics  terminals. 
Often  the  same   CPU  is   doing  some  batch  processing  in  background  while 
also  running  a  timesharing  service   at  standard  keyboard  terminals. 
Such  a  configuration  tends   to  reduce  the  superficial  cost   of  the 
graphics   support,  but  results   in  an  unpleasant   degradation  in  system 
performance.      Discrete  response  time   at  the   graphics  terminals   is   long. 
Certain  resources,   such  as   CPU  core   aJLlocated  to  the   graphics  terminals, 
remain  idle  much  of  the  time   and  so  reduce  batch  and  timesharing 
capabilities;    and  certain  often  trivial  graphics   operations,   such  as 
pentracking,    can   completely  saturate  the   CPU.      On  the   other  hand,   to 
dedicate  the   CPU  to  graphics   support  quickly  increases  the  cost. 

Recently,   a  compromise   of  sorts  has   come  into  increasing 
prominence.      A  small,   or  relatively  small,   general  purpose   CPU 
(8  to  32  k  of  core,   $15,000  to  $100,000  price  range)   is  used  to  perform 
the  local  functions    (such  as   display  manipulation,   data  structure 
creation,  parameter  assignment,  prompting,   etc.)   needed  to  effectively 


interact  with  a  user  at  a  display  console   ($30,000  to  $90,000  price 
range)   in  a  relatively  fast  response  environment.        This   smaJ-l  CPU 
is   attached  in  satellite  mode  to  a  large   central  CPU  which  provides 
library,   doc\imentation,   and  particiilarly  nuniber-cr\anching  analysis 
facilities.      Hence,   after  specifying  his  problem,   the  console-user 
theoretically  has  to  endure   a  long  response  time   only  when  analysis 
is   being  performed  in  the   central  CPU.      However,   "long"   in  this 
case   is   only  the   analysis  time,  not   analysis  time,  plus    card  punching 
time,  plus   turn-in  time,  plus  backlog  time,  plus  print  time,  plus 
return  time . 

Yet  many  problems   still  persist.      l)   The  satellite  CPU  is 
typically  capable   of  only  supporting  one   display   console,   so 
per-terminal  investment  is   still  not  small.      2)   The  satellite   CPU 
is   incapable  of  some   forms   of  desirable  operations    (such  as  picture 
rotations).      3)   The   satellite  CPU  has  very  limited  data  storage 
capabilities,   thus   limiting  picture   coii5)lexity  and,  more  important, 
severely  limiting  the   amo\ant  of  necessary  library  information  that 
can  be   stored  locally.      Hence,    access  to  the   central  CPU  library 
becomes  very  frequent   as  the  number  of  users   and  the  library  grow. 
This   lengthens,   in  turn,   response  time   for  fimctions    (such  as  picture- 
sub-pictxire   generation)   that  are   considered  "local   functions."     h)   The 
speed  of  the   data  linkage  between  the  satellite   and  central  CPU's  is 
a  critical  factor  in  the   amount   and  type   of  data  that  can  be  passed 
back  and  forth.      This   affects  the   division  of  labor  between  the  CPU's 
and  the   consequent  response  time   at  the  display  console.      5)   Resources 
in  the   central  CPU  are   still  wasted,   since   allocation  of  resources 


must  be  made   at  the  beginning  of  a  session,   even  though  actual 
analysis  and  maximum  utilization  may  not  occur  until  the  end. 

The  purpose   of  a  graphical  simulation  system  is  to  aid  a 
user  in  defining,   analyzing,   and  solving  his  particular  problem. 
Certain  terms   just  mentioned  mxost  be  stressed:      "aid"  and  "his 
particular  problem."     First,   the   system  must  strive  to  avoid  hindering 
the   user  or  complicating  his  problem  solving  attempts  "with  system- 
dependent   details   and  restrictions.      This   is,   of  course,   an  ideal  in 
a  world  where  most   users   are  people  not  intimately  familiar  with 
computers,  but  who  want  to  use  them  in  pxirsuing  their  other  work.      By 
necessity,    any  system  miost  have   certain  formalisms   and  conventions, 
but  these   should,   and  must,  be   implemented  such  that  they  are  natural 
arid  convenient  to  the  neophyte,   as  well  as  the  experienced,   user. 
Presently,   most  systems   are  bvirdensome   and  lack  adequate  prompting 
and  self  teaching  facilities. 

Second,   the   system  should  attempt  to  solve   as  wide   a  range   of 
problems   as  possible.      This   is  easy  to  say — it  is  what  most  people 
usually  try  to  accomplish — but  it  is   a  goal  quite   difficult  to  attain. 
Generality  usually  means   obtaining  resiolts   for  a  specific  problem  in 
more  time   than  would  be  needed  by  a  special  purpose   approach.      Hence, 
in   designing  a  system,   the   class   of  problems  to  be   solved  is   often 
chosen  so  that  the   differences   from  one  problem  to  another  will   ca\ase 
a  relatively  insignificant   change   in  approach,   and  thus,   in  system 
performance.      Unfortunately,  when  the  system  is   implemented,    certain 
system  characteristics   (core  space,   data  structure,  etc.)  usually 
decrease   the   acceptable  problem  class.      In  addition,   implementation 


of  the   analysis  proceedures   usually  makes   use  of  many  element 
dependent   characteristics,   such  as   in  electrical  network  analysis 
programs.      That  is,   an  electrical  network  analyzer  cannot  do  much 
with  a  chemical  cracking  plant  piping  network,   althougti  both  are 
topologically  similar.      Naturally,   the   class   of  acceptable  problems 
is    further  reduced;   the  user's   "particular  problem"  becomes  very 
particular  indeed.      Presently,  most  systems   support  special 
purpose   graphics   interfaces  to  at  most   a  few  special  purpose 
analysis   packages. 
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FOOTNOTES 


Be firming  with  Sutherland's    classic   "SKETCHPAD"   in  1963,    graphics 
terminals   and  their  applications   as   flexible  man-machine  interfaces 
have  been  speedily  proliferating.      Interested  readers   shotild  scan 
such  publications   as  Datamation,   Computers   and  Automation,   Informa- 
tion Display,   and  IEEE  Spectrum  to  get  an  idea  of  the  hardware/ 
software   commercially  available.      For  a  state-of-the-art  view,    a 
good  starting  point  would  be  AFIPS,    and  ACM  Conference  Proceedings 
as  well  as  proceedings   from  special  interest  conferences,   such  as 
the   recent   "Pertinent   Concepts   in  Computer  Graphics,"  University  of 
Illinois,   March  19^9 .     A  historical  perspective  of  graphics   in  the 
computer  field  can  be  obtained  from  articles   such   as  the  one  by 
Hobbs . 

The   adage   "everybody's   doing  it"   applies   directly;    almost  every 
technical  journal  in   any  field  contains   articles   about  simulation 
of  phenomena  peculiar  to  that   field.      Areas   of   application   range 
from  the   obvioiJS    (aircraft   design   and  circmt   analysis),   to  the 
more   obvious    (business   management   and  stock  market  trends).      Places 
to  look  besides   specific  professional  Journals   include  the 
communications   of  the  ACM,   Simulation,    and  IEEE  Proceedings. 
GeneraJ.   articles   include  those  by  Harmon,   Blake,    and  Shigley. 

Typical  systems   include   aircraft   design   (Lockheed),    automotive 
design   (General  Motors),   NASA  space   simulation   (General  Electric), 
electrical   circuit  analysis    (ECAP  variations),    IC  design   (MIT), 
ship  building  design   (CDC),    chemical   cracking  networks    (Brown), 
ad  infinitum.      Simply  look  for  simvilation  studies;    a  graphical 
implementation  is  often  included. 

The   DEC   338  and  IBM  1130-MOD  IV  are   typical  examples   of  the   low 
and  high  ranges,    respectively,   of  such  systems. 


II.   A  DESIRED  ENVIRONMENT 

The  goal  in  designing  a  graphical  sim\ilation  system,  as 
indicated  in  the  previous  section  is  l)  to  use  a  hardware  configuration 
that  reduces  the  cost  per  terminal  while  maintaining  the  capabilities 
and  response  of  a  dedicated  system,  and  2)  to  enlarge  the  class  of 
acceptable  problems  that  the  system  can  deal  with.   This  is  Just  the 
universal  "more  product  for  less  investment"  goal;  the  question  is  the 
usual~HOW? 

Until  the  time  that  a  small  CPU  and  display  console  can  be 
built  economically  as  a  single  \init  to  be  attached  directly  in  time- 
sharing mode  to  a  central  CPU,  the  use  of  an  intermediate  satellite 
CPU  will  be  necessary.   However,  as  previously  discussed,  several 
deficiencies  exist  in  present  graphical  console,  satellite  CPU,  central 
CPU  configurations.   To  alleviate  these,  the  following  provisions  should 
be  made : 

1.  The  satellite  drives  a  multiple  number  of  consoles. 

2.  The  satellite  has  a  local  mass  storage  facility. 

3.  A  high  speed  data  link  exists  between  the  two  CPU's. 
Supporting  many  terminals  with  one  satellite  will  drive  down  the  average 
cost.   Local  mass  storage  reduces  the  need  to  access  the  central  library. 
A  high  speed  data  link  makes  central  library  accessing  and  other 
necessary  data  transfers  low  in  cost  with  respect  to  time. 

Two  main  problems  in  supporting  a  multi console  environment  are 
initial  picture  generation  and  picture  refreshing  for  each  individual 
console.   During  picture  generation,  a  large  amoiint  of  data  manipulation 
is  necessary,  along  with  a  high  frequency  of  library  accessing.  Hence, 
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if  the   satellite   is  "busy  generating  a  picture  for  one   console   and  a 
second  console   requests   service,   the  response  time   at  the   second 
console  will  be   greatly  delayed.      Moreover,   all  the   data  structures 
associated  with  the   current  pict\ares   on  the   consoles  will  not   fit  in 
the  satellite's   core   simultaneously.      For  picture  refreshing,    a 
display   file  must  "be   continuously  available  to  drive  the   console   CRT. 
With  multiple  terminals,   there  will  not  be  room  in  the   satellite's 
core   for  all  of  these  necessary  files  either.      These   considerations 
lead  to  the   conclusion  that  the   display  data  structures   and  at  least 
a  sub-library  reside  on  a  local  mass   storage   device   so  that  particular 
items  needed  at   any  time   can  be   obtained  relatively  quickly.      In 
addition,   the   display  files   for  picture   generation  and  refreshing  must 
reside  on  some  mass   storage   device,  preferably,   one  that   can  automatically 
refresh  the  pictures   on  all  consoles  without  use   of  the   satellite .CPU. 
This   last  notion,   in  turn,   necessitates   a  controller  to  interface  the 
satellite   CPU  with  a  mass   storage   device   and  the  individual  tenninals , 
performing  such  functions   as   regenerating  the   displays,    changing 
appropriate   display  files  when  requested,   and  queuing  all  terminal 
interrupts.      If  possible,   one  mass   storage   device   for  all  the   functions 
mentioned  (library  storage,    data  structure  storage,    display  file  storage) 
would  be  preferred.      The   resulting  hardware   configuration  desired  is 
presented  in  Figure   1. 
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Figure  1. 
Hardware  Configuration 
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Since  graphics  consoles  are  being  \ised,  the  acceptable  class  of 
problems  should  be  anything  that  can  be  represented  on  the  display  surface 
for  which  the  user  can  describe  the  various  elements  and  their  inter- 
connections.  Thus,  for  example,  the  system  should  handle  an  electrical 
network,  or  a  piping  network,  or  a  bridge,  or  two  levers,  or  a  horse  race, 
or  a  glop  of  cytoplasm,  assuming  that  the  respective  users  can  supply  the 
appropriate  equations,  parameters,  and  constants.   A  somewhat  detailed 
description  of  one  way  of  providing  this  information  is  presented  in  a 
paper  by  C.  W.  Gear  cited  in  the  Bibliography.   In  general,  the  system 
should  allow  a  user  to  create  any  kind  of  a  pictorial  element,  define  its 
action  with  any  combination  of  equations,  constraints,  connection  points, 
constants,  parameters,  etc.,  and  then  use  these  elements  to  represent 
his  particular  problem.   Of  course,  if  a  set  of  elements  such  as 
resistors,  capacitors,  etc.,  for  a  particular  type  of  problem  has  been 
previously  defined,  this  set  will  be  available  in  the  library  system  for 
other  users,  who  simply  connect  them  as  appropriate  and  supply  new 
parameters.   The  data  structure  representing  the  completed  problem  state- 
ment is  then  sent  to  the  central  CPU  for  analysis. 


In  order  to  provide   analytic  flexibility  in  the   centraJ.  CPU 
for  such  a  problem  class,   two  approaches   can  be  taJcen.      First,  many 
analysis  prograjns   for  certain  restricted  types   of  problems   currently 
exist.      These  programs  usually  assume  some  type  of  symbolic  input  and 
range   from  non-interactive  to  highly  interactive.      A  table-driven  or 
compiler- compiler  designed  symbolic  manipulation  interface  program 
could  scan  the  problem  data  structure,   and  create   symbolic  input  for 
whichever  analysis  package  the  user  may  have  specified.      This  would 
make   a  fast   special  purpose  package,   rather  than   a  slower  general 
package,    available   for  the  problem — assuming  such  a  package  for  the 
problem  exists   at  all.      The   output   from  these  programs,  whether 
interactive  or  not,    could  then  be  sent  to  an  applications   drawing 
program  which  would  produce   a  data  structure  suitable   for  creating  a 
display  on  the  terminal.      So  the  input,   analyze,   and  output  cycle 
is   complete. 

On  the  other  hand,  packages   do  not  exist   for  many  problem 
types.      In  this    case,    a  general  purpose  package    (differential  equation 
solver)   must  be   ijsed.        But  here   the   symbolic  manipiilation  interface 
need  only  produce  one  type  of  output,   although  the  type  of  syntax  and 
other   checking  performed  by  it  may  be   considerably  more   complex  than 
in  the   case   described  above.      The   output  from  this  type   of  analysis 
package  would  also  be  passed  to   an  application   drawing  program  to 
comm\micate   results  to  the   terminals.     Actually,   there   is  no  reason 
why  both  approaches    cannot  be   used  in  the  system,   leaving  the   choice 
to  the   individual  user  as  best   s\aits  his  needs. 
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The  software  environment  in  which  the  three  essential  analysis 
coniponents    (namely,   symbolic  manipulation  interface,    analysis  packages, 
and  applications    drawing  package)   must  operate  has  been  stated  and 
in^jlied  in  this   and  the  previous   section.      To  review  and  restate 
briefly,   l)    communications   and  control  executives  must  be   in   operation 
in  both  the   central  and  satellite   CPU's,   2)    an  information   retrieval 
facility  must  be   available  to  both   CPU  systems  with   a  permanent  main 
library  in  the   central  computer  and  an  optimized  temporary  sub-library 
in  the   satellite,    and  3)    a  data  structure  management   and  display  file 
generation   facility  with   drawing,   picture/subpicture ,   tex±,    and  prompting 
facilities   must  be   available   in  the   satellite   for  direct   communication 
with  each  terminal  user.      In  addition,   the  executive   system  of  the   central 
CPU  must  utilize   temporarily  uniised  resources    allocated  to  support  of  the 
satellite   in   order  to  improve   the  efficiency  of  the   central  CPU.      One  way 
of  accomplishing  this   last   requirement  is   to  provide   for  the   rxmning  of 
background  utility  packages  whenever  space   is  not  being  entirely  taken  up 
by  symbolic  manipiilation,    analysis,   or  drawing  packages.     Explicitly, 
terminal   users    could  send  commands   to   a  sub-monitor  to  operate   on  some 
previously   constructed  symbolic   file.      This   file   contains    control  and 
source   information  similar  to  a  batch  input  stream,   and  the   sub-monitor 
schedules   translators   and  processors   for  execution  accordingly.      If 
communication  were   established  between  the   graphics   support  executive   and 
the   time-sharing  executive,   this   facility  would  be   opened  to  all  non- 
graphics  terminals   in  the   system,    and  the   files   used  could  be   conveniently 
located  in  the   time-sharing  filing  system.      Furthermore,    certain  types   of 
problems    can  be   stated  on   an  ordinary  keyboard  type  time-sharing  terminal, 
such  as   algebraic   analysis,   language  translation,   etc.      This   input   co\ild 
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be  interfaced  to  other  analysis  prograrns   in  the  simiilatlon  system. 
Hence,   the  system  could  support  the  maximum  facilities  that  any 
particular  terminal  can  handle,  while  increasing  the   availability  of 
the  system  from  a  limited  number  of  graphics  users  to  all  terminal 
lasers.      The   desired  software   configuration  is  presented  in  Figure  2. 
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Figure  2. 
Software  Configuration 
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FOOTNOTES 


An  alternative  is  to  use  storage  tubes,  but  these  add  the  problems 
of  resolution,  decay,  inability  to  partially  update  a  picture, 
erase  time,  higher  cost  (typically),  etc.   However,  some  systems 
using  this  technique  have  been  built,  particularly  the  one  by 
Engelbart,  Stanford  University. 

2 

A  good  example  of  a  state-of-the-art   general  differential  equation 

package   is  the  ODESSY  system  under  development   at  the  University  of 

Illinois,   Department  of  Con^uter  Science   (c.f.    Dill,   C.   et  al.). 
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III.   PROPOSED  SYSTEM—AN  OVERVIEW 

A.  Hardware 

The  GRAS  System,  cvirrently  imder  development  to  meet  the 
previously  mentioned  requirements,  utilizes  the  following  hardware 
in  a  configuration  identical  to  that  in  Figvire  1: 

PDP8  as  the  satellite   CPU 

Display  Processing  Unit   (DPU)    as  the  terminal  controller 

Eight  Graphics  Terminals  with  Joystick,  keyboard,   and 
function  keys 

Head  per  track  disk  as  the  local  mass   storage   device 

2701  Parallel  Data  Adapter  for  data  transmission 

360/75   as  the   central  CPU 
In  particular,   the  PDP8,   2701,   and  360/75   are  only  being  used  in  the 
prototype   system  because   they  are   available;   the   disk,   DPU,   and 
terminals   are   inhoiise  pieces   of  equipment  whose   designs  have  been 
geared  to  the  requirements   of  the  project. 

The  PDP8  is  a  general  purpose   computer  with  four  Uk  banks 
of  12-bit  per  word  core  memory  and  I/O  interrupt  facilities.      It 
interfaces  with  the  DPU,   disk,   and  2701  as  well  as  with  a  teletype 
console  and  a  low  speed  printer. 

The  DPU  takes   a  standard  display  file   (in  this   case,   338  code) 
from  PDP8  core   and  executes   it,   thus  producing  a  3-bit  incremental  code 
to  drive   a  terminal  CRT.      Decoding  logic   at  the  terminal  interprets  this 
3-bit   code,   moves  the   CRT  beam  accordingly,   and  thus  produces   a  visible 
image.      The   display  file   is   "executed"  by  the  DPU  only  once;  the 
resulting  incremental  code  is  stored  on  a  track  of  the  disk  (each  terminal 
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is   associated  with  one  particular  disk  track).      Subsequent  refreshing 
is   done   directly  from  the   disk  by  feeding  the   contents   of  the  appropriate 
track  to  each  terminal's   decoding  hardware,   all  simultaneously  and 
without  interrupting  the   CPU  or  using  CPU  core.      The  DPU  also  queues 
interrupts   from  the  various  terminals   and  passes  this   information  to 
the  PDP8  on  demand.      Hence,    different  displays   can  be   continuously 
serviced,    changed,   and  refreshed  at  a  multiple  number  of  terminals 
without   overloading  the  PDPS's   interrvipt  struct\ire   or  available   core. 

Each  terminal  has   a  CRT,   joystick,  keyboard,   and  fxmction 
keys.      The   joystick,  which  replaces   the  use   of  a  light  pen  for  inputting 
XY  coordinate  information,  has   a  locally  produced  (i.e.    local  to  the 
terminal)    cursor  indicating  its  position  on  the  screen.     However,   an 
interrupt   occurs,   making  XY  information  available,   only  when   a  button 
is  pressed.      So  the  user  can  move  his   cursor  all  over  the  screen  without 
bothering  the   CPU  until  he   really  wants   to.      Unlike   a  light  pen,   the 
joystick   can  be  used  to  input  XY  information  from  blank  areas   of  the 
screen;  hence,  the  pen  tracking  problem,    and  the   associated  high  density 
of  interrupts   is  eliminated.      A  "dxunnQr  generation"   (i.e.    comparator) 
mode  is   available  in  the  DPU,   enabling  access  to  display  file  status 
and  addresses   in  the  manner  xisually  available  with  standard  display 
devices.      (The   joystick   could  be   directly  replaced  by  a  data  tablet 
using  a  discrete  interrupt   type  pen.)     Keyboard  input   is  buffered  and 
displayed  locally,   one   line   at   a  time.      That  is,   the  user  can  view  the 
current   line  being  typed  and  will  interrupt  the   CPU  only  when  the  line  is 
completed.      As  previously  mentioned,   all  terminal  interrupts   are  filtered 
through  the  DPU  before  reaching  the  PDP8."^ 
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The   disk  is   a  high   capacity,  high  rate  device  with  head-per- 
track  hardware.      Each  of  its   32  tracks   contains   about  100,000  bits — 
the  equivalent  of  l6k  PDP8  words    (i.e.    all  four  banks).      The  transfer 
rate  is   2  usee,   per  word,   so  an  entire  bank   (U096  words)    can  be  brought 
into  the  PDP8  in  an  average  time   of  about  25  mlsec.    (at  I8OO   rpm 
yielding  an  average  rotational  delay  of  IT  mlsec).      Due   to  the  head- 
per-track  feature,    all  displays   can  be  simultaneously  refreshed,   as 
mentioned  in  the  DPU  section.     With  hardware   and  software  sectioning, 
this   one   disk  performs   all  three  mass   storage  fimctions  mentioned  in 
Section  II.      The   assumption  of  eight   graphics   terminals   is  made   for  the 
following  discussion,   and  it  should  be  noted  that  each  disk  track  is 
hardware   divided  into  12  sections. 

Eight  of  the   32   disk  tracks   are  hardware   allocated  to  the 
DPU  for  the  refreshing  of  the  eight   graphics  terminals.      Each  of  the 
tracks   appears  to  the   respective  terminal  as   a  continuous   streajn  of 
100,000  bits    (33,000  incremental   codes).      Eight  other  tracks   are   software 
allocated  for  full-bank  task  switching.      This   space  is   used  to  save   the 
current  picture   data  structure,    display  file,    and  program  status   for  each 
terminal  as   swapping  in  and  out  of  core  becomes  necessary  to  service   the 
various  terminals.      One   track  is   software   allocated  for  loadable  systems 
programs  needed  in  the  PDPB.      Each  program  is   located  at  a  specific 
track  position  for  rapid  read-in.      The   remaining  15   tracks   are   software 
allocated  for  library  space.      On  these   tracks,   each  sector  is  viewed  as 
containing  ten  blocks   of  128  PDP8  words  each,   or  I8OO  total  blocks   for 
the   15  tracks.      Since  reading  and  writing  on  the   disk  is  possible  by 
sector  only,   an   additional  "selective  read"  hardware   facility  has  been 
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added.      This   allows   any  pattern,   and  particularly,   as   fev  as   any  one, 
of  the  ten  blocks   in  a  sector  to  "be  read  sequentially  into  the  PDP8. 
For  exaniple,  blocks   0,   1,   5,    and  8  in  sector  k  of  track  10   could  be 
specified,   and  blocks  0,   1,   5,   and  8  would  appear  contiguovisly  in 
PDPB  core.      Hence,   since  reading  is  the   dominant  operation  involved 
in  creating  a  display  file,   selective   access  to  particularly  small 
blocks   in  a  relatively  large  local  data  base  offers   a  distinct  saving 
in   computer  time. 

The  2701  is   a  standard  high  speed  transmission   device  with  a 
data  rate   of  about  0.5M  cps .      At  this   rate,   an  entire  PDP8  bank  can  be 
read-in  or  written-out  in  about   50  mlsec,  making  significant  data 
exchanges  between  the  two   CPU's   relatively  comfortable. 

The   360/75    (under  MVT)  ,  while  supporting  standard  batch  and 
time-sharing  facilities,   provides   a  permanent   region  for  supporting 
the   satellite   CPU.      In  this   region,   coniputational  power  as  well  as 
access  to  extensive  231^  disk  storage  is   available.      Effective  utilization 
of  these   resources  while  not  in  use   for  PDP8  requests   is   discussed  later 
in  this   section. 

B.      Software 

The   GRASS  software   configuration  is   similar  to  that  in  Figure  2. 
A  description  of  each  component   is  presented  after  the   following  summary 
of  a  typical  user's   session. 

Support  for  the   satellite  in  the   central  CPU  and  the  satellite 
operating  system  have  been  previously  initialized,   and  several  users   at 
other  graphics   terminals   are  variously  creating  elements,   stating 
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problems,   requesting  analysis,   and  viewing  resiilts .      The  new  laser 
activates  his  terminal  and  "signs-on"  with  valid  identification 
information.      After  requesting  that  certain  subsets   of  his  personal 
library  and  of  the   general  library  be  transferred  to  the  local  system, 
he   constructs   some  new  elements    (personal),   changes   some  old  elements 
(personal) ,    and  then  begins   defining  a  problem  situation  with  both  old 
and  new,  personal  and  general,  elements.      Later,  he   directs  the  system 
to  update  the   central  library  with  the  new  and  altered  items,   to  save 
the  problem  situation   (really  just   an  element  in  the  library),    and  to 
purge   the  local  system  of  the  library  items  he   requested  (courteously 
leaving  more   local  space   for  users   still  defining  problems).      Since  he 
asks   and  finds  that  space  exists  in  the  background-utility  job  queue, 
the  user  passes  the  system  the  name   of  a  batch-type   file  to  be 
executed  (he   created  this   file   at   a  standard  time-sharing  keyboard 
console  that  morning) .      The  user  then  specifies  the  interface   and 
analysis  packages  that   are   required  for  the  problem  he  has   just   defined 
and  requests   analysis   of  that  problem  to  begin.     While   awaiting  the 
resiilts,  he   is  notified  that  his  background  job  bombed  due   to  incorrect 
control  cards   at  statement  137.      Requesting  service   as   a  tenrporary 
time-sharing  console,  the  user  corrects  his   file;  he  exits   from  time- 
sharing mode   and  finding  the  background  job  queue   again  low,   re-enters 
his   job.      The   results   of  the  requested  analysis  have  become  ready,   so 
he  examines  them,    decides  to   change   some  parameters,   and  analyzes  them 
again.      This  process   continues   until  a  satisfactory  resiilt  is   obtained, 
after  which  the  user  requests  hardcopy  output   (which  is  produced  at  some 
later  time,   offline).      The   viser  requests  that  his  new  problem  be   added 
as   an  element  in  the   general  library  and  "signs-off". 
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When  an  interrupt  occurs  at  a  terminal,  indicating  that 

servicing  of  the  terminal  is  reqviired,  that  interrupt  is  processed  on 

several  levels.     First,  the  DPU  tests  to  see  if  the  interrupt  type 

has  been  enabled,   and  if  it  was  not,   the  interrupt  is  ignored  (joystick 

inhibit,  pushbutton  disable,  keyboard  disable,  etc.).      Otherwise,   the 

interrupt  is  queued  by  the  DPU  for  processing  by  PDP8  software  whenever 

the  PDP8  is   free.      At  the  next  level,  when  the  PDP8  begins  processing 

the   interrupt,   the  PDP8  executive  program  first  tests   a  software' 

status  mask  for  the  terminal.      This  mask,   set  by  some  program  operating 

under  the  executive   and  currently  handling  communications  with  the 

terminal,    can  specify  whether  the  interrtrpt  is   a  Class   I  or  Class  II 

interrupt.      Class   I  interrupts  merely  reset  certain  bits   in  the  mask  or 

raise  various  software  indicators   for  the  terminal.      Processing  of  these 

interrupts    (such  as  keyboard  characters,   or  perhaps   certain  p\ishbuttons , 

etc.)   only  requires  the  executive,  which  clears  the  interrupt  condition 

when   finished.      Class   II  interrupts    (such  as  Joystick,   end-of-line 

character,   some  other  pushbuttons,   etc.)   require  task  switching.      In 

this   case,   the  required  program  (if  not   already  present)    and  associated 

data  structures   for  the  terminal  must  be  bro\ight  into  PDP8  core   from 

the  program  (l  track)    and  swapping   (8  tracks)    areas   of  the   disk.     At  the 

final  interrupt  level,  when  the  swap  is   completed,   control  is  passed  to 

the  lower  level  communications  program  which  examines  the  interrupt 

information  in  detail  and  performs  the  necessEiry  operations    (usually 

changing  the  picture  at  the  terminal).     This  program  then  exits  to  the 

executive   and  processing  of  the  next   Class   II  interrvrpt  begins.     Note 

1 
that  while  the   Class   II  interr\:^t  was  being  processed,  the  executive   could  j 

still  process   all  Class   I  interrupts  that  migjit  have  occurred.     Vflien  the     _  { 
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lower  program  retiirned  to  the  executive,   it  specified  which  banks   of 
core  were  to  "be  saved  for  the  terminal  and  any   changes   desired  in  the 
ici-minal  mask. 

The   above   chain  of  events   for  interrupt  processing  in  the 
satellite  implies   the   activities   of  the  major  software   con^jonents   of 
GRA.SS  at  that  end  of  the  system.      The  executive    (GLASP)   is   responsible 
for  all  interrupt  scheduling  in  the  PDP8.      GLASP  maintains  the  terminal 
masks   and  other  terminal  status   information   ( current  program,  bailks 
saved,   etc.),   initiates  task  switching,    and  provides   software   linkages 
between  lower  level  programs   and  system  utilities    (remote   data  trans- 
mission,  library  requests,   print  requests,   etc.). 

The   lower  level  program  (FLOG)   manipulates  picture   data 
structures,    creates   display  files,   initiates   action  in  the   central 
CPU,    and  prompts  the  user  at  the   terminal.      Whether  the   data  structiore 
was    created  by  user  interaction  with  FLOG  on  the  PDP8  or  by  a  program 
in  the   central  CPU  and  then  transmitted  to  the  PDP8  is   irrelevant. 
Hence,   FLOG  is   the  two-way  link  between  the  terminal  user  and  remote 
analysis   or  utility  packages   in  the   central  CPU. 

When  FLOG  needs    data  from  the   library — usually  during  generation 
of  a  display  file — a  call  is    created  to  the  satellite  portion  of  the 
information  retrieval  facility   (GIRLS).      Since   the  storage   capacity  of 
the   disk   at  the  PDP8  is   relatively  limited,  the   complete  permanent  system 
library  must  be   located  at  the   central  CPU.      Normally,   requests   to  this 
permanent   library  are  made  by  interface   or  application  programs   in  the 
central  CPU  or  by  the  portion  of  GIRLS  resident   in  the  PDP8.      Use-count, 
protection,    and  hierarchy  information  in  the   central  library  is    combined 
with  space   and  contents   information  about  the   local  disk  whenever  the  PDP8 
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makes   a  library  request.      As  mentioned,    a  user  typically  will  request 
his   own  sub-library  plus   other  subsets   of  the  system  library  at  the 
beginning  of  a  session.      The  most   often  used  items — consistent  with 
protection,   space   availability,    and  items   already  on  the   local   disk — 
will  then  be   transferred  to  the  PDP8.      Thereafter,   most  items   needed 
by  the  user  will  be   readily  available   locally,    and  only  occasional 
references   to  the  permanent   library  will  be  made.      Hence,   GIRLS   attempts 
to  optimize   retrieval  in   a  double  ended,   unbalanced  system. 

Swapping  and  program  requests   from  GLASP   and  specific   library 
requests   for  GIRLS   are  handled  by  a  disk  access   software  package    (DOOFIS). 
DOOFIS  provides   routines    for  controlling  the  program,    swapping,    and 
library  sections   of  the   disk  by  sequential -block  or  track-sector-block 
numbering  schemes.      Inline    coding  is   losed  to  move  entire   swap  banks   or 
program  code   at  high  speed  on   single   disk  transfers   into  the  PDP8.      Other 
routines  handle  selective-read   (single   transfer)   or  blocked- read  (buffered 
transfer)    and  blocked-write    (buffered  transfer)    requests   to  the  library 
section   of  the   disk. 

The   flow  of  control  in  the   support   region   of  the   central  CPU 
is   similar  to  that  in  the  satellite.      All  input  from  and  output  to  the 
PDP8  passes   through   an  executive    (GASP).      Each  input   line   from  the  PDP8 
has    a  terminal  identification   character  in  it,    and  each   graphics    (or 
other)    terminal  has   a  control  block   associated  with  it.      When   an   input 
line   is   received,   GASP   checks   the   respective    control  block   (as   indicated 
by  the   ID  character)   to  see  if  a  user  has   successfully   "signed-on"  yet. 
If  one  has  not,   the   line  is  passed  to  a  "sign-on"  monitor  for  inspection; 
if  one  has,   the  block  is    checked  for  the  presence   of  an  attached  subtask. 
If  a  subtask  is  not  present ,   the   line   is   sent  to  a  control  monitor.      This 
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monitor  performs   functions   for  the  terminal,   such  as  passing  commands  to 
the  background  job  queue,    creating  subtasks    (any  interface,   analysis, 
applications,   etc.,  programs),  passing  requests  to  the   central  CPU 
portion  of  GIRLS,   and  passing  lines  to  the  time-sharing  executive.      If 
a  subtask  is_  present,   the   line   is  enqueued  for  later  passage   to  it 
(a  special   control  character,  however,    can  be   used  to  cause  the  input 
line   to  be   sent  to  the   control  monitor  even  when  in   "subtask  mode"). 
Depending  on  the   amount   of  central  CPU  core   available,    any  number  of 
systems   terminals    can  be   in   any   combination   of  control  or  subtask  mode, 
with  the  backgroimd  job  processor  running  as  well.      Hence,   if  all 
terminals  were   "signed-on",  but  in   control  mode,   the  backgrovmd  job 
processor  woiold  be  making  use   of  practically   all  of  the   resources 
allocated  to  graphics   support — resources  that  ordinarily  would  be   idle. 

The   central   CPU  section   of  GIRLS   is   a  permanent   subtask   of 
GASP,   thus  making  it   continually  available   for  PDP8  requests   or  central 
CPU  program  requests.      It    contains    all  routines   for  updating,   extracting, 
and  monitoring   (use-count  protection,   etc.)    information  in  the  permanent 
library. 

Although  any  program  can  be   attached  by  GASP  as   a  subtask  for 
a  terminal,   the  usual  package   contains   an  interface,   analysis,    and 
applications   group;    or  a  sequence   of  attaches  will  bring  such  a  grouping 
into  execution   consecutively.      This   allows    complete   flexibility  for  the 
user  to  determine  what  interface   and  analysis   routines  he  wishes  to   apply 
to  his  particular  problem. 

An  interface    (SYMP)    takes   a  data  structure   as   input,    converts   it 
to  symbolic  strings   or  another  data  structure   as  necessary   (depending  on  the 
type   of  analysis  program  that  will  be  used) ,   and  checks  the  result   for 
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syntactic   correctness.      In   converting  the  input   data  structure,   SYMP  may 
make   calls  to  GIRLS  to  evaluate   items   used  as   sub  elements.      The   finished 
information  is  passed  directly  for  analysis   or  stored  in   a  data  set  for 
the  next  attach   (i.e.    the   analysis  program  is  not  yet  in   core). 

The   analysis  program  (GEAR)    can  be   of  any  type,    accepting 
data  in  structured  or  symbolic  form,   interactive  or  non-interactive,   etc. 
As   output  is  produced  it  is   sent   to   an   applications  program  to  be   recon- 
verted to   a  data  structure   suitable   for  input  to  FLOG  in  the  PDP8. 

Applications  progrsums    (GADS)   used  in  the   system  can  have 
picture-subpicture   facilities    and  access  to  GIRLS,   thus  making  them 
more  powerful  than  most  packages   of  this  type.      Optimally,   there  would 
be   only  one   GAD  used  by   all   GEARs . 

To  summarize  briefly — by  using  generalized  FLOG,   SYMP,    and 
GADS  packages   to  link  users  with   GEAR  or  the   utility  package,   GRASS 
atten5)ts  to  enlarge   the   applicable  problem  class   and  eliminate  much 
of  the   inflexibility  prevalent   in  most   current   systems.      By  utilizing 
some   special  hardware    (disk,   terminal  controller,    and  graphics  terminals) 
in   conjunction  with  a  satellite-central  CPU  configiiration  operating 
\inder  suitably  designed  executives,    GRASS   attempts   to  mak.e   a  powerful 
graphics   system  available   at   a  reasonable   cost  per  terminal,  while 
maintaining  a  high   degree   of  dedicated  service   at  the  terminal  and  a 
high  efficiency   rate   at   the   central   CPU. 
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FOOTNOTE 


For  a  coniplete   description  of  the  functioning  of  the  DPU  and  for 
additional  information  about   the   disk,   consiolt  the  Masters   Thesis 
by  R.   Hostovsky,   Department  of  Computer  Science,   University  of 
Illinois,   Urbana,   Illinois. 
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IV.      GASP/GLASP 

A.      Current   Implementation 

The   desired  prototype   configioration  will  not  be   available 
until  sometime   after  January  1970.      The  DPU  and  terminals   are  in  the 
design  stage,   and  the   disk  hardware   is  being  debugged  and  the  software 
for  it  implemented.      Access   to  a  large    CPU  is   restricted  to  a  360/50 
via  a  low  speed  link  through  a  PDP7  until  the   arrival  of  another 
2701  PDA. 
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Figure   3. 
Current  Hardware   Configuration 


Interim  versions  of  GASP  and  GLASP  (hereafter  referred  to  as 
GRAFMON  and  UIM0N8,  respectively)  using  the  available  configuration  of 
Figure    3  have  been  implemented.      Items   to  note   are: 

1.  Only  a  single   graphics   terminal  is   attached  to  the  PDP8. 

2.  Only   a  restrictive,    low  speed  data  link  to  the   large 
CPU  is   available. 

3.  The   large   CPU  is   operating  imder  MET  with  a  resident 
ASP  system. 
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This  interim  conmimi cations  system  enables  graphics  programs  in  the 
PDP8  to  interact  with  support  packages  in  the  360/50,  although  the 
effectiveness  and  flexitility  allowed  is  not  comparable  to  that 
which  will  be  typical  in  the  completed  system. 

After  initiating  GRAFMON  support  in  the  /50  CPU,  the  user 
brings  UIMGNS  into  PDP8  core.   He  can  then  communicate  directly  with 
GRAFMON  over  the  PDP8  teletype  console,  directing  it  to  bring  a 
specific  module  into  the  /50,  to  pass  a  data  set  to  time-sharing,  or 
to  load  a  data  set  into  PDPB  core  to  run  under  UIMONB.   Typically, 
the  user  would  load  a  drawing  program  into  the  PDPB  and  a  library 
module  into  the  /50.  He  would  then  proceed  to  construct  a  problem 
situation  on  the  33B;  the  completed  data  structure  wovild  be  trans- 
mitted to  and  stored  by  the  library  module.   Control  would  be  returned 
to  UIMONB  and  GRAFMON,  respectively.   The  user  then  requests  an 
interface,  analysis,  and  applications  module  (or  requests,  in  order, 
each  one  separately)  to  perform  the  desired  analysis  whose  results  are 
stored  in  the  /50  library.   The  process  then  continues  in  this  fashion 
until  satisfactory  results  are  obtained. 


26 

B.      360  Section 

1.      General  Description 

GRAFMON  support  for  the   360/50  graphics   area  consists   of 
a  non-terminating  monitor  em,d  a  comprehensive  set  of  communications, 
translation,   and  data  definition  macros  for  programs  running  under 
the  monitor. 

The  monitor  consists  of  three  segments:      initiator  modules, 
a  permanently  resident  SVC,   and  a  comm-unications  module.     The 
initiator  modiile   uses  the  SVC  to  save   information  about  the  graphics 
partition  on  a  disk  data  set.      Then  the  initiator  overlays   itself 
with  a  very  small  bootstrap  module,  which  in  turn  brings   in  the 
commimi cations   module.      Data  transmission  between  the   360/50  and  the 
PDP8  is  now  possible,   and  the  PDP8  can   request   certain  functions,   such 
as   data  set  transmission,   linkage  to  the   Time-Sharing  partition,   and 
load  module  execution.      To  execute   a  load  module   (e.g.,    analysis, 
interactive,   or  utility  programs),   the   commvuai  cat  ions  module  overlays 
itself  with  the   desired  module.     Upon  normal  termination  of  the   called 
module,    control  is   retxamed  to  the  bootstrap,  which  loads   in  a  fresh 
copy  of  the   comm\mi cations   module,   and  the  process   continues.      If, 
however,  the   called  module  abnormally  terminates,   control  is  passed  to 
the  MFT  ABEND  module.      Due  to  the  SVC,   and  some   changes   in  ABEND,   the 
graphics  partition  is   rebuilt  using  the  information  stored  by  the 
initiator  on  the   disk.      Control  is  passed  back  to  the  bootstrap,   and 
processing  can  still  continue   as   if  the  ABEND  had  not  occurred. 
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2.      Macros 
The   following  macros   are   available  to   360/50  programs   for 
commtini cation  with  the  PDP8  via  the  PDPT: 

PDP7IN  —call  PDP7EXCP  to  input   data 

PDP70UT  — call  PDP7EXCP  to  output   data 

PDP7TR  —call  PDP7EXCP  subroutine   for 

data  translation 
PDP7EXCP  —perform  I/O  operations 

nDC  — assembly  time  macro   for  defining 

data  and  character  strings 
A  complete   description  of  each  macro  is    contained  in  Appendix  A;    a 
brief  description  follows  here.      A  detailed  siommary  of  360-PDP7-PDP8 
communication  characteristics   is   cQ'Htained  in  Appendix  C. 

PDP7IN   creates   a  calling  sequence  to  an  I/O  routine   in 
PDP7EXCP.      This   sequence   specifies   the   data  input  location,  the   amount 
of  data  expected,   and  the   addresses   of  error  routines.      Similarly, 
PDP70UT  creates   a  corresponding  sequence   for  data  output.      As   mentioned, 
PDP7EXCP   contains  the   actual  I/O  routines  needed  for  commijnication. 
These   routines   start  the   I/O  operation,  wait  for  completion,    check  for 
errors,    and  move   data  as   appropriate  between  user  areas   and  their  own 
buffers. 

PDP7TR  provides   the   data  translation  facilities  necessary  for 
converting  360  formatted  data  into  PDP7-PDP8  formatted  data  (c.f. 
Appendices   C  and  D).      The  user  specifies   one   of  eight  translation  types, 
the   location  of  the   data,   and  the  length  of  the   data.      Translation  is 
performed  in_  place. 
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nDC  defines   character  and  numeric  data  at  aaseinbly  time  in 
PDPT-PDP8  format.      Hence,   data  known  to  "be  needed  in   advance   does  not 
have  to  be  translated  during  execution.      This   is  particularly  usefiil 
for  specifying  error  messages,   display  files,  etc.     The  macro  has 
default  input  and  output  character  sets,  but  these  may  be  overridden 
by  the  user. 

C.   PDP8  Section 

1.   General  Description 

The  UIM0N8  monitor  system  provides  routines  for  communication 
among  PDPB  programs ,  360  programs ,  and  users  at  the  PDP8  teletype 
console,  as  well  as  facilities  for  the  general  convenience  of  all  users. 

UIM0N8  resides  entirely  in  bank  3  of  the  PDP8.  Also,  all  of 
bank  1  is  used  as  a  buffer  area  when  the  text  editor  is  being  used, 
and  the  first  three  words  of  bank  0  are  used  to  link  to  the  interrupt 
handler.  Locations  0  through  i+TTT  of  bank  3  contain  the  UIM0N8 
program.  The  area  from  5000  through  5TTT  is  reserved  for  user  routines 
(page  zero  of  bank  3  is  completely  filled  with  constants  and  save  areas 
for  the  UIM0N8  system;  users  may  use  the  constants  and  pointers ,  but  may 
not  use  any  of  the  storage  areas)  and  the  area  from  6000  through  6tTT 
contains  the  character  generator  (part  of  the  remaining  area  is  "FREE" 
space  to  be  used  by  a  larger  character  generator  with  the  last  couple 
of  pages  in  core  being  reserved  for  the  resident  routines  of  the  future 
disk  facilities).   Programs  running  under  UIM0N8  operate  in  banks  0,  1, 
or  2;  use  the  UIM0N8  interrupt  handler  for  interrupt  processing;  and  uses 
the  UIM0N8  transmission  routines  for  sending  and  receiving  data. 


29 

After  UIM0N8  is  in  PDP8  core,  it  can  be  directed  to  enter 
one   of  several  modes.      The   first   allows   direct  teletype   communication 
with  GRAFMON.      In  this  mode,   the  user  specifies  modules   to  be   loaded 
into  the   /50,   into  PDP8  core,   or  sent  to  time-sharing.     Another 
provides  a  local  graphics  text-editing  facility  for  bviilding  sym- 
bolic files.      These   files   can  be  printed  on  the  teletype,   stored  on 
magnetic  tape   locally,   or  sent  to  the  time-sharing  filing  system. 
A  third  mode   stores   specified  PDPB  core  images   in  time-sharing  files. 
These   "programs"   can  then  be  reloaded  into  the  PDP8  at   a  later  time 
and  executed.      Finally,   the   338  can  be  used  as   a  high  speed  graphics 
time-sharing  console. 

When  UIM0N8  "exits"  back  to  the  PDP8  operating  system, 
only   control  has  been   lost;   the  program  itself  is   still  in  bank   3. 
Hence,   the  user  can  specify  another  PDP8  program  to  be   loaded  into 
banks   0,   1,   or  2.      This  new  program,   in  turn,   simply  restores  words 
1,   2,    and  3  of  bank  0    (for  the   interrupt  handler)    and  turns  the  PDP8 
interrupt  hardware  on.      The  user  program  is  now  running  "under" 
UIM0N8  and  may  use   any  of  its   communication  and  interrupt  facilities. 

2.      Routines 


The  following  routines  are  available  to  programs  running 
mder  UIM0N8  in  the  PDP8: 

For  processing  all  individual  device  interrupts 

INTHND 
For  sending  data  to  the  360  system 

ASYSMSG 

PSYSMSG 
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For  receiving  data  from  the  36O  system 

MSGES 
LOAD 

For  communicating  with  the  user   via  the  teletype 

SYSMSG 
SYSERR 

The   system  interrupt  handler  is   table   driven,   utilizing  two 
tables:      one  with   clear-flag  or  test-flag  lOT's   and  the  other  with 
corresponding  device   routine   addresses.      Hence,   to  ignore   interrupts 
from  a  particular  device,   it  is  merely  necessary  to  change   a  test- 
flag  lOT  in  the  first  table   to  a  clear- flag  lOT.      Then,   if  an  interrupt 
occurs   from  that   device,   the   flag  will  automatically  be   cleared  and  a 
branch  to  the   device  routine  will  not  be  initiated.      The   converse 
procedure  is   used  to  accept  interrupts   from  vario\is   devices.      Clearly, 
if  a  user  desired  to  handle  interrupts   from  a  particular  device    (such 
as  the   light  pen)  himself,   all  that  is  necessary  is   for  him  to  save 
the  system  routine   address   in  the  second  table   and  substitute  the 
address   of  his   own  routine.      This   is   one   of  the  main  reasons   for 
reserving  part   of  bank   3  for  user  routines,   i.e.    for  use  by  user's 
interrupt  routines.      Hence,   each  Mser  who  wishes  to  use   any  of  the 
peripheral  devices   of  the  PDP8  need  not   construct  his   very  own  interriipt 
handler,  but  need  only  write  routines  to  handle  interrupts   from  devices 
for  which  system  routines   do  not  meet  his   speciaJ.  needs    (c.f.    descrip- 
tion of  interrupt  tables.   Appendix  E). 
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For  commToni eating  with  the  360  system  two  buffers  for 
input  and  output,  named  respectively  SBUFF  and  UBUFF,  are  main- 
tained along  with  several  flag  words.   A  special  "FILTER"  routine 
(GM0N8)  looks  at  every  input  line  from  the  36O  to  see  if  it  begins 
with  a  valid  control  character.   These  control  characters  cause 
the  input  line  to  be  passed  to  a  particular  routine  associated  with 
each  character.   Hence,  a  form  of  message  switching  is  obtained; 
that  is,  information  can  be  sent  intermittently  to  varioios  routines 
in  the  PDP8.   As  an  example,  assume  an  interactive  graphics  program 
is  running  in  the  PDP8  with  an  analysis  or  interpreter  program  in 
the  360.   If  the  36O  sent  a  line  to  the  PDP8  with  an  invalid  control 
character,  the  line  (assumed  to  be  a  system  message)  woiold  be 
automatically  printed  on  the  teletype  and  the  user  could  type  a 
coded  response  (c.f.  description  of  SYSERR  routine.  Appendix  B). 
The  360  program  could  have  specified  the  control  to  call  "LOAD",  in 
which  case  the  input  line  is  assiomed  to  be  data  in  core  load  format. 
This  type  of  input  (being  data  directed  in  nature)  coiold  have  replaced 
part  or  all  of  the  current  display  file,  set  switches  for  the  execu- 
ting program,  or  could  have  consisted  merely  of  input  data  to  go 
into  a  user's  own  input  buffer,  or  do  anything  else  that  a  clever 
user  might  desire.   Or,  the  36O  might  have  sent  the  control  for 
entering  the  debugging  package;  or  the  36O  might  have  sent  the  control 
indicating  that  the  input  line  was  to  go  to  the  current  input  routine 
which  might  have  been  some  other  system  routine  or  a  particular  routine 
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of  the  user.   All  of  the  above  input  operations  are  performed  with 
no  effect  on  the  currently  executing  program  in  the  PDP8.   In 
addition,  since  the  control  characters  are  associated  with  routines 
via  a  table,  the  user  can  add  new  ones  or  redefine  old  destinations, 
etc. 

It  is  hopefully  obvious  at  this  point  that  input  from  the 
360  to  the  PDP8  is  handled  practically  on  an  automatic  basis  with 
the  main  constraint  being  that  the  input  data  is  of  the  proper  format. 
Hence,  the  major  programming  of  input  formatting  winds  up  being  done 
in  the  36O ,  where  clearly  programming  is  much  easier  for  the  average 
user.   (in  addition,  when  FORTRAN  and  PL/I  interfaces  are  provided 
at  the  360  end — work  in  progress — easy  communication  will  exist  for 
just  about  anyone.) 

For  transmitting  data  to  the  36O,  things  are  a  bit  more 
complex,  but  equally  as  flexible  for  the  PDP8  user.   To  send  core 
image  data,  i.e.  data  that  may  represent  any  bit  pattern,  the  routine 
PSYSMSG  can  be  used.   This  routine  can  be  called  from  any  bank  and 
will  send  a  core  block  to  the  36O  as  specified  by  the  length,  bank, 
and  starting  address  information  supplied  in  the  calling  parameters. 
Each  PDPB  word  is  converted  to  two  8-bit  characters  to  insure  that 
no  PDPT  control  characters  are  accidentally  transmitted  (c.f.  descrip- 
tion of  PDP8  data  formats.  Appendix  D,  and  PSYSMSG  routine.  Appendix. 
B).   To  send  ASCII  character  data  to  the  36O,  the  routine  ASYSMSG  is 
provided.   This  routine  assumes  that  UBUFF  contains  a  control 
chajracter  of  the  user's  choice  followed  by  the  ASCII  message  (one 
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character  per  word),  followed  by  a  carriage-retiim.  The  utility  of 
this  routine  is  made  much  clearer  by  the  descriptions  of  the  SYSMSG 
and  MOVEDT  routines. 


3ii 
V .      CONCLUSIONS 

Although  the  system  outlined  in  this  paper  and  the  sections 
implemented  so  far  indicate  to  the   author  that  this  will  prove   a  viable 
solution  to  the  problems    discussed,   it  is,   ion  fortunately,   still  too 
early  in  the  implementation  stage  to  state   conclusively  that  the  final 
system  will  indeed  prove   successfiiL. 
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APPENDIX  A 
360  Macros 
For  all  macros,   0S/36O  linkage   conventions   apply.      A 
detailed  a-uimnary  of  36O-PDPT-PDP8  I/O  conventions,   formats    and 
restrictions    appear  in  Appendix  C. 
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MACRO   CALL: 

latel  PDPTIN       AREA=label,LEN=m,MSG=label,ERR=la'bel,SOP=label,EXT=Y 
Description: 

This  macro  causes  the  next  input  record  from  the  PDPT  to  "be 
put  into   core   at  the  location  specified  by  the  AREA  operand.      The 
amovint   of  data  passed  to  the   user  is  equal  to  the    (HEX)   niomber  of 
bytes   specified  by  the  LEN  parameter  plus   one ,   the  last  character 
being  a  carriage -ret urn    (X'8D").      If  80   column  card  images  were 
expected,   LEN=80  should  be   coded  and  8l   characters  would  be  transferred. 
(When  scanning  an  input  string,  the   user  need  only  scan  for  the   carriage- 
retiim  rather  than  keep  a  character  coxmt.      Also  if  the  string  were 
shorter  than  expected,   a  carriage -ret urn  from  the  PDP8.will  appear 
earlier  in  the   record  indicating  the  end  of  the   line.      Of  coiirse ,   if 
the   record  length  is   \jnknown,   a  request   for  a  maxim\im  length  record 
is  best.)      LEN  must  be    <_  125.      Both  AREA  and  LEN  may  be   specified  as 
residing  in  registers,   e.g.   AREA=(5)   means   the   address   of  the  input  area 
is   in  register  5.      LEN=(6)   means  the  length  of  the   input   request  is   in 
register  6. 

The   input  operation  can  have  three  possible  results:      success 
with   data  received,   success  with  a  system  code  received,   or  EXCP 
channel-error   (very  rare).      Three   corresponding  parameters  may  be   coded. 
For  any  not   coded  control  passes  to  the  next  sequential  statement  after 
the   calling  sequence. 

SOP=lab  — control  passes  to  "lab"  if  data 

successfxilly  received  . 
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MSG=lab  — control  passes  to  "lab"  if  a 

system  message  is   received.      In 
this   case,  bytes  0  and  1   (A  and 
B)   instead  of  data  bytes   are 
placed  in  the   first  two  bytes 
of  the  loser's   input   area  for 
examination. 
ERR=lab  — control  passes   to  "lab"   if  channel- 

error  occurs.      Best   action  is  to 
assume   line  lost  and  indicate   same 
to  user  with  sysmessage   facility. 
Hence,   effect   retry. 
If  EXT=Y  is   coded,   the   appropriate   linkage   for  an  externally 
defined  PDPTEXCP  CSECT  will  be   generated   (c.f.   PDPTEXCP  macro). 
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MACRO   CALL: 

label  PDPTOUT       AREA=label,LEN=in,ERR=label,SOP=label,EXT=Y, 
SYS=nn,   MON=nn 
Description: 

This  macro  caioses  the  output  record  at  the   core  location 
specified  by  the  AREA  operand  to  be   sent  to  the  PDPT.      The   amount  of 
data  passed  to  the  PDP7  is  equal  to  the    (HEX)   n\imber  of  bytes 
specified  by  the   LEN  parameter.      LEN  must  be   <_  12U.      Both  AREA  and 
LEN  may  be   specified  as   residing  in  registers    (e.g.   PDP7IN). 

The   output  operation  can  have  two  possible   results   analogous 
to  the  read  operation:      success  with  data  sent,   or  EXCP  channel-error 
(very  rare).      (c.f.   PDP7IN  for  a  description  of  ERR  and  SOP.)      The 
action  of  EXT=Y  is   identical  to  the  PDPTIN  case. 

The   data  line   sent   to  the  PDPT  is   formatted: 

AB[NX.  ..X  CR— Junk— ]CR 
01    23        k   k+1    k+2  126  127 

where  A  and  B  are  PDPT- 360/50  system  coxmauni cation  bytes,  N  is  the  PDP8 
graphics  monitor  byte,  bytes    3  through  k  are  the   data  bytes,  byte  k+1 
is   a  carriage -return   (X'8D')   inserted  by  PDPTOUT,  bytes  k+2  throiigh  126 
are   junk  from  previous   operations    (these   are   ignored  by  the  PDPT) ,   and 
byte  12T  is   a  mandatory   carriage -re turn   (X'8D')   inserted  by  PDPTOUT.      If 
12i|  data  bytes  had  been  specified,   there  would  be  no  "junk"  bytes,   and 
the   carriage -re  turn  at  bytes  k+1  and  12T  woiold  coincide   at  byte  12T. 
The   SYS  and  MON  operands   are  used  to  specify  bytes  B  and  N. 
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For  SYS: 


00  =  Time  Sharing  OFF 

01  =  Time  Sharing  ON 

02  =  Log  In 

03  =  Log  Out 
OU  =  Data  Line 


For  MON: 


8U  =  Input  Data 

A3  =  System  Message 

80-83,   85-86  =  System  Options 
NOTE:  User  default   options   are   SYS  =  OU,   MON  =   8i+. 

The  user  may  specify  MON  =  A3  for  transmitting  lines   to  the 
system  message   device.      All  other  codes   are   for  systems  maintenance 
and  are  password  protected  at   this   time. 


MACRO   CALL: 

PDPTEXCP        EXT=Y,DDNAME=PDPTDD 
Description: 

This   macro   actually  perforins   input/output  operations  with 
the  PDPT  when   called  via  PDPJIN  and  PDPTOUT.      PDPTEXCP  must  be  present 
if  either  PDPTIN  or  PDPTOUT  is   used,   unless  EXT=Y  is   coded  for  PDPTIN 
and  PDPTOUT.      Then  PDPTEXCP  with  EXT=Y  must   appear  in   another  CSECT 
in  the   same   load  module.      The  DDNAME  operand  specifies  the  name   of  the 
DD   card  that   indicates   UNIT=PDPT  to  the   operating  system,  with  the 
default   DDNAME   being  PDPTDD. 

PDPTEXCP  should  be   the   last   statement   in   an   assembly  or  if 
it   is  not,   any  statements  that   come   after  must  be  named  as   a  new  CSECT. 
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MACRO  CALL: 

label  PDPTTR        n ,LAB=latel ,LEN=m,EXT={X,Y} 
Description: 

Depending  on  the   first   operand,  n,  this  macro  translates 
blocks   of  data   (<_  256   characters)    at   run  time   from  one   format   into 
another.      The   LAB  operand  specifies  the   location  of  the  block  to  be 
translated,    and  LEN  specifies   its   length   in   (HEX)   bytes.      Both  LAB 
and  LEN  may  be   specified  as   registers    (c.f.    PDP7IN).      On  the   first 
occurrence   of  a  call   for  each  type   of  translation  where   the  EXT 
operand  is  not   coded,   the  translation  table   and/or  routine   is   generated 
in   addition   to  the   calling  sequence.      Each   subsequent   call   for  a 
particular  translation  type   results   in  only  the   calling  sequence 
being  generated.      If  EXT=Y  is   coded,   only  the   calling  sequence   is 
generated  and  the   translation  table   and/or  routine   is   assiomed  to  be 
externally   defined.      If  EXT=X  is    coded,   only  the  translation  table 
and/or  routine   is    generated  and  calls   are   assumed  to  be   externally 
defined.      (NOTE:      PDP7EXCP  and  all  the  translation  tables   and/or 
routines   could  be  put   in  one   central   "input/output"   CSECT.      Other 
CSECTS  would  only  need  to  use  the   calling  sequences,  PDPTIN,  PDPTOUT, 
and  PDPTTR. 

There   are   eight  translation  types    defined  at  present: 

n  =  1  — translates   from  EBCDIC  to  ASCII. 

2  — translates    from  EBCDIC  to   coded 

(6  bit)   ASCII. 

3  — translates  from  EBCDIC  to  coded 

(6  bit)  BCD 
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k^  — translates  from  /360  half  words 

(right  12  hits)  to  pairs  of  coded 
(6  hit)  hinary. 

5  —ASCII  to  EBCDIC. 

6  —coded  ASCII  to  EBCDIC. 

7  —coded  BCD  to  EBCDIC. 

8*  — coded  hinary  pairs  to  /360 

half  words . 
For  n=l,   2,    3,   5,6,   orT   carriage-return    (X'8D')    and  line 
feed   (X'BA')    are  preserved  hy  the  translation.      For  example,    if  X'8A' 
is   the   last  hyte   in   an  EBCDIC  string  heing  converted  to  6  hit   coded 
ASCII    (n  =  2),   the   corresponding  hyte  in  the  resultant  string  is   still 
X'BA'. 


*     LEN  is  the  number  of  half  words   to  he  transmitted. 
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MACRO  CALL: 

label  nDC   'message ' ,{OWN=} 
Description: 

This  macro  allows  data  definition  at  assembly  time  of 
ASCII,  coded  ASCII,  coded  BCD  and  octal  data,  depending  on  the 
character  n. 

Forms : 

*n  =  A  — define  the  EBCDIC  characters 

enclosed  in  apostrophes  as 
ASCII  character  data  (i.e.  lab 
ADC  'IJK'  becomes  lab  DC  X'C9CACB'). 
*n  =  B  — define  the  EBCDIC  character  enclosed 

in  apostrophes  as  coded  ASCII 
character  data  (i.e.  lab  BDC  'ABC 
becomes  lab  DC  X'8281|86'). 
%  =  C  — define  the  EBCDIC  characters 

enclosed  in  apostrophes  as  coded 
BCD  character  data  (i.e.  lab  CDC  'ABC 
becomes  lab  DC  X'E2EUe6'). 
n  =  0  — define  the  octal  nijmerals  as  four 

digit  octal  nximbers  in  6  bit  coded 
binary  (i.e.  lab  0DC  173  becomes 
lab  DC  X'82F6' ). 
n  =  D0  — define  the  decimal  number  as  one 

four  digit  octal  number  in  6  bit 
coded  binary  (i.e.  lab  DODC  123 
becomes  lab  DC  X'82F6'). 
*  "  or  8e&  used  to  define  '  or  &  may  not  be  split  into  two  card  images. 
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The  OWN  operand  is  valid  with  n  =  A,  B,  C,  only  and  can  be 
used  to  redefine  the  output  character  set  of  an  nDC  definition.   The 
OWN  operand  specifies:   l)  that  an  internal  redefinition  is  being 
performed  (and  not  a  data  definition),  and  2)  the  number  of  characters 
in  the  message  that  replace  each  character  in  the  output  character 
set.   For  example,  ADC  ' C10102C3' ,0WN=2  would  cause  the  output  equivalent 
of  B,  C,  and  D  for  subsequent  ADC  definitions  to  be  changed  from  C2 ,  C3, 
and  Ck   to  01,  02,  and  03,  while  keeping  CI  for  A  and  all  the  other 
character  definitions  as  previously  defined  as  well,  i.e.  before 
ADC  'ABCD'  became  DC  X'C1C2C3C5';  now,  ADC  'ABCD'  becomes  DC  X' C1010203' ) . 

Also,  the  user  may  change  the  standard  character  set  if  he 
desires  by  use  of  the  STAWTAB  L,  message  macro.   For  example, 
STANTAB  1,  '3^+5'  would  change  A,  B,  and  C  to  3,  1+,  and  5,  i.e.  formerly 
ADC  'ABCD'  became  DC  X'ClC2C3Cl|'  now  ADC  '3U5D'  becomes  DC  X' C1C2C3CU' ) . 
Hence,  the  user  may  completely  alter  the  character  definition  facilities 
if  so  desired.   (NOTE:   l)  any  character  set  may  not  exceed  150  items, 
2)  replacement  by  use  of  OWN  is  character  by  character  beginning  with 
the  first  character  group  in  the  OWN  "message"  replacing  the  first 
character  result  in  the  output  set  and  continiiing  sequentially  only 
until  the  "message"  is  exhausted.   Hence,  resultant  groups  in  the  output 
set  not  affected  by  the  OWN  "message"  remain  as  previously  defined. 
Users  must  exercise  care  in  changing  the  character  sets  to  insure  that 
mixed  length  definitions  within  a  set  are  not  created,  3)  error  checking 
is  difficult  and  expensive  for  this  macro  and  is  not  extensive:   xisers 
are  urged  to  be  very  careful  and  follow  procedures  for  its  \ise  closely) . 


1+6 


APPENDIX  B 
UIM0N8  Routines 
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All  user-oriented  routines  in  the  UIM0N8  system  assume  a 
JMS  type  call  with  the  "IF"  field  set  to  30  and  the  "DF"  field  set 
to  the  calling  bank,  i.e.  the  called  routine  will  return  to  the  user's 
program  with  the  "IF"  and  "DF"  fields  set  to  the  value  of  the  "DF" 
field  at  the  time  of  the  caJLl. 

ROUTINE :   ASYSMSG 

FUNCTION:   Send  a  line  of  ASCII  characters  to  the  360 

CALLING  SEQUENCE:   ACC  =  Nximber  of  characters  to  be  sent 

(including  a  trailing  carriage-return) 
DESCRIPTION : 

The  routine  assumes  that  a  line  of  ASCII  characters  with 
one  character  per  word  is  already  in  UBUFF.   This  line  is  sent  to 
the  360.   If  an  error  in  transmission  occurs,  or  if  at  sometime 
during  the  transmission  the  36O  sends  a  message  to  the  PDP8,  this 
message  will  be  printed  on  the  teletype  followed  by  the  sequence 
"CODE:".   If  the  user  types  a  zero,  the  transmission  operation  will 
be  terminated.   However,  any  other  character  will  cause  the  operation 
to  be  retried. 

UBUFF  may  be  filled  by  the  user  with  the  aid  of  the 
"MOVEDT"  routine  or  the  SYSMSG  facility  (c.f.  the  descriptions  of 
these  routines).  NOTE:   No  output  line  may  exceed  125  (DEC) 
characters,  including  the  carriage-ret\am. 
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ROUTINE:   PSYSMSG 

FUNCTION:   Send  a  line  of  core  image  data  to  the  36O 

CALLING  SEQUENCE:   ACC  =  Number  of  PDP8  words  to  be  sent 

PARAMl  =  LOG-1  of  the  data 

PARAM2  =  CDF  NN  specifying  the  hank  of  the  data 
DESCRIPTION: 

The  routine  ass\xmes  that  a  user  control  character  of  some 
sort  is  in  the  first  word  of  UBUFF.  Each  PDP8  word  in  the  block  to 
be  sent  is  converted  to  two  characters  in  the  coded  data  format 
(c.f.  description  of  data  formats)  and  is  placed  into  UBUFF 
following  the  control  character.   Then  a  carriage -ret  Tim  is  added, 
and  the  line  is  sent  to  the  36O  in  the  same  manner — and  with. the  same 
error  control — as  with  ASYSMSG. 

NOTE:   Since  no  output  line  may  exceed  125  (DEC)  characters, 
the  macim-um  number  of  words  in  the  block  is  61  (DEC). 
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ROUTINE:   MSGES  (not  iiser  callable) 

FUNCTION:   Receive  system  messages  and  put  into  SBUFF 
CALLING  SEQUENCE:   ACC  =  Last  input  character 
DESCRIPTION : 

The  routine  sets  the  "GOl"  UIM0N8  system  flag  immediately 
(thus  inhibiting  system  routines  from  sending  data  to  the  630),  and 
sets  the  "SYSFLG"  when  the  entire  message  has  been  received.   The 
input  message  will  be  printed  on  the  current  SBUFF  printer  when 
"UPRIN"  (the  system  buffer  controller — not  user  callable)  or 
SYSERR  (user  callable)  are  called. 
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ROUTINE :      LOAD 

FUNCTION:      Insert  loader  -  formatted  data  from  the   360  into  PDP8  core 
CALLING  SEQUENCE:      ACC  =  Starting  address   for  data 

PAJRAM  =   CDF  NN  specifying  the  bank 
DESCRIPTION: 

The   routine   assumes  that  the   input   data  is   in  loader  format 
(c.f.    data  formats);  hence,   each  input   character  is  6  bits   of  data  or 
6  bits   of  location  information.      The  routine   continues  loading  data 
until  it   receives   an  end-of-data  character   (211  octal).      Since  the 
input   data  can  be  of  any  amount   and  req_\aire  more  than  one   input  line, 
carriage-returns   and  line   feeds   are   ignored  \antil  the  EOD  character 
is   received.      The   routine   can  be   called  explicitly  by  a  user's 
program  in  anticipation  of  a  data  transmission  from  the   360.      However, 
if  the   input   is  properly  formatted,   this   routine  will  be   automatically 
called  by  GM0N8   (the   remote-input   filter  routine).      With  the   automatic 
call  feature,   and  with  location  information   capabilities   in  the   input 
stream,   this   routine  provides   an  easy  method  for  automatic  data  input, 
display  file  updating,   switch  setting,   remote  program  loading,   etc. 

NOTE:      This   routine  is   really  a  load-and-go  routine  with  a 
few  special  switches   and  options.      When  the  EOD  character  is   received, 
the   routine   checks  the   contents   of  its   core   address  pointer.      If  the 
pointer  is  not   zero,   the   routine  uses  that   information  plus  the 
current  bank  information  as  the   starting  address  of  a  program  and 
branches  to  it.      If  the  pointer  were   zero,   the  routine   simply  exists 
to  the  program  that   called  it.      Hence,   all  blocks   of  data  that   are 
sent  through  the   loader  must  have  the   final  three   characters  before 
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the  EOD  character  specifying  new  location  information.  This  new 
location  must  either  be  the  starting  address  of  the  program  in  the 
case  of  a  program  load,  or  must  be  zero  in  the  case  of  a  simple  data 

load. 
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ROUTINE:      SYSMSG 

FUNCTION:      Communicate   fixed  messages  to  the  user  via  the  teletype 

and  format  output   lines   from  the  user's   responses. 
CALLING  SEQUENCE:      ACC  =  N  where  N  is   a  number  >  =  0   specifying  a 

particular  message   residing  in  a  message 
table   defined  by  the  \iser  at  system 
initialization. 
DESCRIPTION: 

The   routine   assumes  that   a  message  table  exists  beginning 
at  location  5000   in  bank   3,   i.e.    at  the  beginning  of  the   user's   area. 
This   table   is  placed  into   core  by  the   viser,   either  by   a  call  to  move 
the  table   from  the   user's  program  in  another  bank,  by   a  call  to 
dectape,   or  by  a  call  to  the   disk  routine.      If  a  response   is   expected, 
the   routine  places  the   resxilting  teletype   characters   into  UBUFF 
beginning  at  a  location  specified  by  the  message  table.      Hence,  by 
carefully   constructing  his  table,   the  user  can  automatically  format 
composite  output  lines   from  a  particular  sequence   of  related  inqiiiries. 
The  table  is   formatted  as   follows: 
SYSTBL  -N  Expected  return  count. 

UBUFF+M  ADDR  of  retvim   characters   in  UBUFF. 

MESS0-1  ADDR-1  of  message. 


MESS0 
MESSl 


(Characters  in  packed  format) 


MESSK 
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The  expected  retiom   coimt  includes   a  carriage-retxim  that  the  user  will 
type  to  end  his   response.      So,   if  a  response   of  nine   characters   is 
expected,   -12  would  be   specified.      If  the  response  that  the  user  gave 
was   only  six  characters   instead  of  nine,   the   remaining  character 
spaces   in  the  UBUFF  buffer  would  be  blanked,   and  then  the   carriage- 
return  woxold  be   inserted  into  UBUFF  at  the  end  of  the  nine   character 
field.      If  the   user  tried  to  type  more  than  nine   characters,   the 
message  would  be   retyped.      If  the   user  typed  a  percent   sign,   the 
message  would  also  be   retyped.      If  the  expected  return   covint   is 
specified  in  the  table   as   -1,  no  response   is   assiomed,   and  the   result 
is  that   only  a  message   is   sent  to  the  teletype  with  no  effect  on  UBUFF. 

UBUFF+M  (M>  =  $))    specifies  where   in  UBUFF  the  response  of 
the   user  is   to  be  put.      NOTE:      UBUFF  can  hold  a  maximum  of  125    (DEC) 
characters   including  carriage-retiim. 

MESS0-1  specifies   the  starting  location  of  the  message  to 
be  printed  on  the   teletype. 

-L  specifies   the   length  in  characters   of  the  message.      If 
the  expected  return   covmt  were  -1,   the  system  adds   a  line   feed  and 
carriage-return  to  the  line  printed. 

The  table    (K  entries  of  four  words  each)    is   followed  by 
the  K  variable  length  messages. 

NOTE:      The   user  could  specify  some  other  buffer  area  in 
bank   3  as  the   recipient  of  the  teletype   responses;  however,   if  the 
user  does  this ,   it   is  his   responsibility  to  insure  that  no  part  of 
the  UIM0N8  system  is   damaged. 
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ROUTINE :   SYSERR 

FUNCTION:   Test  the  system  buffers  and  return  a  code  to  the  caller 

CALLING  SEQUDNCE:   None  (ACC  assumed  =  0) 

DESCRIPTION: 

It  is  possible  that  the  360  or  the  PDPT  will  at  sometime 
send  a  message  to  the  PDP8  which  is  unrelated  to  the  user's  program, 
i.e.  time  sharing  off,  et.  al.   If  UIM0N8  is  in  time  sharing  or  text 
editor  mode  at  the  time,  these  messages  would  automatically  be 
printed  on  the  teletype.   However,  in  other  modes  (either  system  or 
user  defined),  immediate  print-out  would  not  necessarily  occur, 
since  printing  is  only  done  when  a  call  to  the  system  print  routine 
is  initiated.   The  con5)lete  arrival  of  a  system  message  is  indicated 
when  UIM0N8  sets  its  "SYSFLG"  to  nonzero.  When  called,  this  routine 
prints  the  system  buffers,  and  then  tests  "SYSFLG";  if  the  flag  were 
up  (nonzero),  the  routine  prints  "CODE:"  and  waits  for  a  teletype 
reply.   This  reply  (a  number  zero  through  seven)  is  returned  to  the 
calling  program  in  the  accumulator,  and  the  "SYSFLG"  is  reset  to 
zero.   Hence,  the  calling  program  has  the  option  of  taking  various 
courses  of  action  for  any  particular  system  message. 
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ROUTINE :   MOVEDT 

FUNCTION:   Move  a  block  of  PDP8  core  to  anywhere  in  the  machine 

CALLING  SEQUENCE:   ACC  =  F0T0  (F=BANK  FROM,  T=BANK  TO) 

PARAMl  =  ADDR  FROM 

PARAM2  =  ADDR  TO 

PARAM3  =  -COUNT  (in  words) 
DESCRIPTION: 

The  data  at  the  specified  "FROM"  address  in  the  "F"  bank 
is  moved  sequentially  starting  at  the  lowest  core  address,  and  is 
moved  to  the  "TO"  address  in  the  "T"  bank.   The  user  is  cautioned 
about  overlapping  fields  and  should  note  that  the  action  of  this 
routine  is  identical  to  a  360  MVC  instruction.   This  is  merely  a 
utility  type  routine  and  is  included  as  a  convenience  for  all  users . 
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APPENDIX   C 
Features   of   36O/5O-PDPT-PDP8  Communications 
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1.     PDP8  to  PDPT  to  360/50 

The  PDP8  transmits   or  receives   one   character  at   a  time  to  or 
from  the  PDPT  at   a  maximum  rate  of  100   characters  per  second.      As   soon 
as  the  PDPT  senses   a  carriage -re turn  character  from  the  PDP8  or  when 
it  has   received  a  total  of  125   characters  without  getting  a  carriage- 
return  character,   the  PDPT  considers  the   "line"   of  characters   from  the 
PDP8  to  be   conipleted.      At  this  time  the  PDPT  transmits   a  carriage- 
return   followed  by  a  line   feed  to  the  PDP8.      The  PDPT  then  tries  to 
send  the  line  to  the   360/5O.      When  the   360/5O   reads  the  line,   and  not 
before,   the  PDPT  sends   a  bell-character  to  the  PDP8  signifying  that  the 
PDP8  may  send  another  line.      If  the  PDP8  should  try  to  send  characters 
to  the  PDPT  before  receiving  the  bell-character,   the  PDPT  immediately 
sends   a  carriage-return  line   feed,    "#WAIT",   carriage-return,   line   feed 
sequence  to  the  PDP8. 

The   format   of  the   line   sent  to  the   36O/5O   from  the  PDPT  is 

as  follows: 

A,B[125   data  bytes  ]CR 
0    1   2  126  127 

Where  A  and  B   (bytes   0   and  l)    are  PDPT- 360/50   control  characters,  byte 

12T  is   always   a  carriage-return,   and  bytes  2  through  126  are   data  bytes. 

If  the  PDP8  had  sent  50   characters   followed  by  a  carriage -re turn,  the  line 

would  look  like: 

A,B[ CR Junk ]CR 

0    12         51  52  126 127 
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2.   360/50  to  PDPT  to  PDP8 

When  the  360/50  sends  data  for  the  PDP8  to  the  PDPT,  the 

data  format  is: 

AB[N 124  data  bytes ]C R 

01    23  126  127 

where  A  and  B  are  PDPT- 360/50   control  characters ,  N  is   a  control 

character  for  the  PDPB  monitor  system,   and  byte  12T  is   always   a 

carri age-ret iim.      If  50   characters  were  to  be  sent  to  the  PDPB,   the 

line  would  be: 

AB[N      CR Junk ]CR 

01  23  52  53  5k  126  127 

The  PDPT  would  send  only  bytes  2  through  53  to  the  PDP8,  followed  by 
an  additional  line  feed  (NOTE:  When  the  PDP8  initiated  a  send,  a  line 
feed  and  a  bell  were  returned;  when  the  /50  initiates  a  send,  only  a 
line  feed  is  additionally  sent  to  the  PDP8.). 

After  sending  one  line,  the  /50  cannot  send  another  line 
until  the  first  has  been  completely  sent  (character  by  character)  to 
the  PDP8.   Note  that  the  PDPT  assumes  the  PDP8  is  a  synchronous  device; 
hence,  the  PDPT  sends  characters  to  the  PDP8  at  a  fixed  rate  and  the 
PDP8  must  accept  them  at  that  rate.   In  order  to  know  when  this  has 
been  accomplished,  the  program  in  the  /50  must  issue  a  READ  operation. 
In  this  case,  byte  1  ('B')  of  the  input  indicates  the  disposition  of 
the  last  line.   (On  ordinary  input,  B  =  0,  meaning  the  line  is  a  data 
line.)  The  rest  of  the  line  is  junk.   If  B  is 

1,  then  the  output  has  all  been  transmitted  to  the  PDP8. 
or       2,  then  the  PDP8  has  requested  the  PDPT  to  stop  transmission 

before  the  entire  line  was  sent,  i.e.  the  remainder  of 

the  line  has  been  volxontarily  lost; 
or       3,  then  the  PDP8  has  "signed  off." 
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Hence,  to  send  several  lines  to  the  PDP8,  the  progrsan  in  the  /50  must 
issue  a  read  before  every  output  operation  (except  the  first)  and 
check  B  for  the  proper  setting. 

3.   Data  Format 
Since  certain  characters,  such  as  carriage-return  and  line 
feed  cause  the  PDPT  to  take  some  action,  data — particularly  object 
code — cannot  be  sent  8  bits  at  a  time  from  the  PDPB;  nor  is  8  bits 
really  convenient  considering  the  12  bit  word  of  the  PDP8.   In 
addition,  the  360/50  cannot  send  data  in  its  original  form  to  the  PDPT 
either,  since  an  inadvertant  carriage  return  in  the  middle  of  the  line 
would  cause  the  PDPT  to  stop  transmitting  to  the  PDP8.   Hence,  all 
data  (except  pure  character  data  sent  only  to  the  time-sharing 
system)  is  sent  in  a  coded  format,  six  data  bits  (half  of  a  PDP8 
word)  per  8  bit  character  at  a  time.   Since  internal  PDP8  characters 
are  6  bits  and  the  transmitted  form  takes  up  8  bits  (l  byte),  conversion 
in  the  360/6O  to  EBCDIC  is  very  neat  and  clean.   Numeric  data  is 
reformed  into  360/50  half  words,  i.e.  one  PDP8  word  of  12  bits  becomes 
2  bytes.   In  the  PDP8  each  incoming  data  byte  is  stripped  of  the  excess 
2  bits  and  every  2  characters  are  packed  into  one  PDP8  word. 
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APPENDIX  D 
PDP8  Data  Formats 
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The  UIM0N8  system  works  with  three  types   of  data — ASCII, 
packed  ASCII,    and  Loader  formatted. 

ASCII   characters   are  stored  one   character  per  word  in  the 
right-most   8  bits.      This   data  is   always   of  a  temporary  nature, 
residing  only  in  buffers   just  prior  to  being  sent  to  the  teletype 
or  to  the   36O ,   or  just   after  having  been  received  from  those   devices. 

Packed  ASCII    (really  6  bit  trimmed  ASCII   corresponding 
identically  to  the   right-most  6  bits   of  regular  8  bit  ASCII 
characters)    is   used  in  the  text  editor  display  buffer,   in  all 
stored  system  messages,    and  is   assumed  to  be  the   format   of  user 
messages   stored  in  the  user's   area  for  the  SYSMSG  facility.      When 
one   of  these  messages   is   to  be   sent  to  the  teletype,   a  system  routine 
unpacks  this   data  into  UBUFF.      Since  the   code   is   6  bits,   there   are 
6k  valid  print   characters   available   in  stored  messages   or  for  display 
in  the  text  editor,   except  that  three  of  these   are   control  characters 
for  the  text  editor.     These  three  are  line  feed  (33),   carriage-return 
(3^),   and  escape   data  state    (35),   all  of  which  should  not  be   used  by 
the   user. 

Loader  formatted  data  is   used  to  pass   arbitrary  bit  patterns 
into  and  out  of  the  PDP8.      Since   certain   characters   are   control 
characters   for  the  PDPT/360  system  (such  as   carriage-return),   UIM0N8 
must   insure  that   such   characters   are  not   sent   accidentally  during  the 
transmission  of  a  data  block.      Hence,   each  PDP8  word  of  data  is   converted 
into  two  characters  before  being  sent  to  the   360.      Each   character  is   of 
the   form  1(6DATA  BITS)0,  with  the  top  six  bits   of  the  PDP8  word  going 
into  the   first   character,    and  the   right-most  six  going  into  the   second 
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character.      Naturally,    data  coining  into  the  system  by  way  of  the   load 
routine  is  of  the  same   form.      The  only  other  characters  in  this  type  are 
carriage-returns    (215  octal),   line   feeds    (212),  EOD   (211),   and  origin 
characters    (20X,  where   X  is   1,    3,   5,   or  T  specifying  banks   0  to   3, 
respectively).      The   only  ambiguity  in  this   setup  is  with  line   feed 
which  could  be  mistaken  for  a  data  character.      However,   line   feeds   are 
only  sent  by  the  PDPT  after  a  carriage-return  at  the  end  of  each  line, 
so  by  definition,   212   is   only  a  line   feed  if  it  occurs   after  a  carriage- 
return.      Whenever  an  origin   character  occurs,   the  bank  information  is 
extracted  and  used  as   the   current  load  bank  for  the  input   data,    and 
the  next  two  data  characters   are   assumed  to  contain  a  new  starting 
address   in  that  bank  instead  of  being  data. 
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APPENDIX  E 
UIM0H8  Interrupt  Tables 
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As  explained  in  Section  IV.  B.  2,  PDP8  routines,  the  first 
table  contains  test  lOT's  for  interrupts  to  be  investigated  and  clear 
lOT's  for  interrupts  to  be  ignored.   The  second  table  contains  the 
address  of  the  routine  to  be  entered  if  the  corresponding  test  lOT 
in  the  first  table  is  successful. 

Both  TORCL  and  INTLST  appear  as  follows  at  UIM0N8  initial- 
ization, and  the  system  assumes  that  the  devices  are  in  this  order. 


TORCL  6031 
60U1 
6631 
6132 
7000 
7000 
7000 
7000 
631U 
676U 
SZA 
INTLST  KEYTS 
TPRTR 
GM0N8 
LPEN 
IRTRN 
IRTRN 
IRTRN 
IRTRK 
IRTRN 
IRTRN 
PBHIT? 
PBHITS 


Ti:ST  KEYBOARD  FLAG 

TEST  TELEPRINTER  FLAG 

TEST  630  REMOTE  FLAG 

TEST  LIGHT  PEN  HIT  FLAG 

CLEAR  MMUAL  INTERRUPT  FLAG 

CLEAR  EDGE  FLAG 

CLEAR  EXTERNAL  FLAG 

CLEAR  INTERNAL  INTERRUPT 

CLEAR  CLOCK  INTERRUPT 

CLEAR  DECTAPE  FLAG 

TEST  FOR  PUSH  BUTTON  HIT 

KEYBOARD 

TELEPRINTER 

REMOTE  FILTER 

LIGHT  PEN 

NO-OP 

NO-OP 

NO-OP 

NO-OP 

NO-OP 

NO-OP 

PUSH  BUTTON  HIT 

IF  PUSH  BUTTON  HIT,   NO-OP 


NOTE:      If  none   of  the   other  devices   caused  an  interrupt,   PBHIT?   is 
entered  to  clear  the   flag;   then  PBHIT?   calls  PBHITS  if  the  flag  was 
on.      Hence,   user's   should  change  PBHITS   and  not  PBHIT?. 
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UIM0N8  System  Locations 
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(All  locations   in  iDajik   3) 

SYSTEM  START  ( "UTIL" ) 1000 

ASYSMSG 1600 

PSYSMSG l6li+ 

LOAD li;6i+ 

SYSMSG 1656 

SYSERR 1731 

MOVEDT 361k 

UBUFF 30  30 

SBUFF 3230 

SYSFLG OOOT 

The  following  routines  may  only  be  called  by  programs 
in  bank  3,  in  the  iiser's  area,  for  example. 

SCSET 1211  (TS  CONSOLE) 

LD36O 1235  (LOAD  360  PARTITION) 

LDPDP8 1261  (LOAD  FROM  36O  INTO  PDP8) 

TEXTED 1306  (TEXT  EDITOR) 

TERMS 1327  (UIM0N8  EXIT  TO  DECTAPE) 

SYSTEM  INTERRUPT  TABLES: 

TORCL li+OO    (TEST  OR   CLEAR   lOT  TABLE) 

INTLST II4I3    (INTERRUPT  ROUTINE   LIST) 
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Character  Code  Eq.uivalences 
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STANDARD 

TYPE  A 

TYPE  B 

TYPE  C 

(EBCDIC) 

(ASCII) 

(CODED  ASCII) 

(CODED  BCD) 

A 

CI 

82 

E2 

B 

C2 

8U 

Ek 

C 

C3 

86 

E6 

D 

Ck 

88 

E8 

£ 

C5 

8a 

EA 

F 

C6 

8C 

EC 

G 

C7 

8E 

EF 

H 

08 

90 

FO 

I 

C9 

92 

F2 

J 

CA 

9k 

C2 

K 

CB 

96 

Ck 

L 

CO 

98 

C6 

M 

CD 

9A 

C8 

N 

CE 

90 

CA 

0 

OF 

9E 

CC 

P 

DO 

AO 

CE 

Q 

Dl 

A2 

DO 

R 

D2 

kk 

D2 

S 

D3 

A6 

Ak 

T 

DU 

A8 

A6 

U 

D5 

AA 

A8 

V 

D6 

AC 

AA 

w 

D7 

AE 

AC 

X 

D8 

BO 

AE 

Y 

D9 

B2 

BO 

Z 

DA 

Bk 

B2 

0 

BO 

EO 

9k 

1 

Bl 

E2 

82 

2 

B2 

EU 

Qk 

3 

B3 

E6 

86 

k 

BU 

E8 

88 

5 

B5 

EA 

8a 

6 

b6 

EC 

80 

T 

B7 

EE 

8E 

8 

B8 

FO 

90 

9 

B9 

F2 

92 

NOT 

87  BELL 

87  BELL 

FA  BELL 

UNDERSCORE   8A  LF 

UNUSED 

FC  LF 

CENTS 

89  EOD 

89  EOD 

89  EOD 

PERCENT 

A5 

CA 

FE 

^ 

AE 

DC 

f6 

< 

BC 

F8 

BC 

( 

AS 

DO 

B8 

+ 

AB 

D6 

EO 

UPARROW 

DE 

BC 

AO 

AMPERSAND 

a6 

CC 

80 

1 

Al 

C2 

9A 

$ 

au 

08 

D6 

« 

AA 

.du 

d8 
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) 

A9 

D2 

t 

> 

BB 

f6 

AD 

DA 

/ 

AF 

DE 

1 

AC 

D8 

> 

BE 

FC 

7 

BF 

FE 

J 

BA 

fU 

NUMSN 

A3 

C6 

EACH 

CO 

80 

1 

A7 

CE 

a 

BD 

FA 

II 

A2 

■  Ck 

BLANK 

AO 

CO 

f8 
BA 
CO 
A2 
B6 
BE 
Dl+ 
9E 
Bk 
DA 
98 
96 
9C 
80 


ALL  TYPES  A.  B,  AND  C  AKE  IN 
HEX  (I.E.  A  =  1010  BINARY) 
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1.  Basic  JCL  for  assembling  360  programs  with 

communications  macros: 

/*ID 

//  EXEC  ASM 

//ASM.SYSLIB  DD  DSN=SySl.MACLIB,DISP=OLD 

//  DD  DSN=SYS3.MACLIB,DISP=0LD 

//  DD  DSN=USER.GRAPHICS,MACLIB,DISP=0LD,UNIT=23li+,    X 

//         V0LUME=SER=UIRUR1 

//ASM. SYS IN  DD  * 

SOURCE  DECK 

2.  To  add  the  object  code  of  properly  assembled  programs 

to  the  system,  change  the  BXEC  ASMLKED  card  and,  after  the  /*,  add: 

//LKED.SYSLMOD  DD  DSN=USER.GRAPHICS .LINKLIB(YOURNAME) ,    X 
//         UNIT=23lU ,DISP=OLD ,V0LUME=SER=UIRUR1 

3.  Basic  360  JCL  for  assembling  PDP8  programs  with  PDP8ASM: 

/*ID 

//JOBLIB  DD  UNIT=23li+,V0LUME=SER=UIRURl,    X 

//  EXEC  PGM=PDP8ASM 

//SYSUTl  DD  UNIT=DRUM,SPACE=(TRK,(10,10)),DISP=NEW 

//SYSUT8  DD  DUMMY 

//SYSUDUMP  DD  SYSOUT=A 

//SYSPRINT  DD  SYSOUT=A 

//SYSIN  DD  * 

SOURCE  DECK 
/* 
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k.     To  put  the  object  code  into  the  monitor  system,  change 

the  SYSUT8  card  to  read: 

//SYSUT8  DD  DSN=USER.GRAPHICS.LINKLIB(YOUMAME),    X 
//  DISP=0LD,UWIT=23lU,V0LUME=SER=UIRURl 

5.   To  pionch  the  object  code  on  a  paper  tape  on  the  PDPT 
in  loader  format,  change  the  SYSUT8  card  to: 

//SYSUTB  DD  UNIT=(CTC,, DEFER) 

and  add  the  following  ASP  control  cards  before  the  JOBLIB  card: 

/^PROCESS  MAIN 

/♦PROCESS  FILE 

/*FORMAL  FI ,DD=SYSUT8,DEST=PUWCHT,C0NTR0L=SINGLE 

/♦PROCESS  PRINT 

/♦ENDPROCESS 
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GRASS  Acronyms 
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Components  of  GRASS  software  support  are: 

DOOFIS:  Disk  Oriented  Operating  and  Filing  System — for 

the  satellite  PDP8. 
FLOG:    Facility  for  Local  Online  Graphics — individual 

graphics  terminal  support  running  under  DOOFIS 

and  GLASP  on  the  PDP8. 
GADS:    GraphicaJL  Applications  Drawing  System — for 

360/75  programs  to  create  displays  for  the 

graphics  terminals  of  the  PDP8. 
GASP:    Graphics  Attached  Support  Processor — 

communications  and  monitor  system  for  the 

graphics  region  of  the  360/75. 
GEAR:    Graphically  Extended  Analysis  Routine — any 

analysis  package  running  xinder  GASP. 
GIRLS:   Graphical-Information  Retrieval  and  Library 

System — an  IR  facility  with  sections  resident 

and  active  in  both  CPU's. 
GLASP:   Graphics  Locally  Attached  Support  Processor — 

PDPS  complement  of  GASP. 
SYMP:    symbolic  Manipulation  Programs — interface  and 

pre-processor  fol:  GEARs. 
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